<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Autoconf</title>
<style type="text/css">
p {
	text-indent: 2em;
}
</style>
</head>
<body>

<h2>1 简介</h2>

<p>有一次，一个物理学家、一个工程师和一个计算机科学家在讨论上帝的本性。 “当然是一个物理学家,” 物理学家说， “因为在创世的早期，上帝创造了光；你知道，麦克斯韦等式，波粒二象性，相对论……” “工程师！，” 工程师说， “因为在创造光之前，上帝把混乱分成了土和水，那会需要大量的工程师来处理泥浆，把固体从液体里分离出来……” 计算机科学家大叫道：“对了，混乱，你们认为它是从哪里来的呢，嗯哼？”</p> 

<p>——匿名</p>

<p>Autoconf是一个生成shell脚本的工具， 该脚本自动配置软件源代码包， 以适配很多不同的POSIX系统。 Autoconf生成的配置脚本在运行的时候是独立于Autoconf的， 所以脚本的用户不需要安装Autoconf。</p>

<p>配置脚本在运行的时候不需要用户的干预； 甚至不需要一个指定系统类型的参数。 脚本会挨个测试软件包所需的系统特性是否存在。 （在每个特性测试之前， 脚本会在屏幕上显式正在测试的内容， 这样用户在脚本执行完成之前不会太无聊。） 因而， 脚本能够应付很多种类型的系统， 也就不需要为每一种类型维护一个特性列表。</p>

<p>使用Autoconf的软件包需要提供一个模板文件， 其中列出所需的系统特性， Autoconf根据这个模板文件生成一个配置脚本。 检测系统特性的代码写成后， Autoconf可以在很多软件包中共享使用。 如果检测代码需要调整， 只需要在一个地方改动就可以了； 所有的配置脚本可以重新生成， 以使用更新的检测代码。</p>

<p>那些不懂Autoconf的人将被惩罚重新发明它， 而且不见得更高明。 Autoconf的主要目标是让用户过得舒服点；让维护者过得舒服点只是次要目标。也就是说， 主要目标不是为了让软件包的维护者自动生成configure （当然有人愿意朝这个方向改进是受欢迎的， 毕竟软件包的维护者是Autoconf的用户基础）； 而是为了让autoconf过的软件包的用户在使用configure时获得舒适性、可移植性和可预测性。 从这一点上来说， Autoconf是很成功的， 对Autoconf的大多数抱怨是难于编写Autoconfshuur， 而不是configure的行为。 甚至不使用Autoconf的软件包一般也会提供一个configure脚本， 对于这些自制的脚本的抱怨一般是说它们不满足GNU编码标准， 因为用户已经习惯了Autoconf生成的configure对GNU编码标准的高度符合。</p>

<p>Metaconf和Autoconf功能类似， 但它生成的脚本需要人工干预， 这对配置大型源代码树非常不方便。 不像Metaconf脚本， 如果适当编写的话， Autoconf脚本能够支持交叉编译。</p>

<p>Autoconf并不能解决和可移植软件包相关的所有问题， 对于完整的解决方案， 就需要其它GNU构建工具例如Automake和Libtool的配合。 这些工具解决诸如生成可移植的、可递归的并且包含标准目标的Makefile， 链接动态库等。</p>

<p>Autoconf对C程序中#if用到的宏有限制。</p>

<p>Autoconf要求GNU M4版本1.4.6或更新以生成脚本。它用到了某些GNU M4版本没有特性，包括GNU M4 1.3</p>

<h2>2 GNU 构建系统</h2>

<p>Autoconf解决了一个重要问题 —— 可靠地发现特定系统的构建时和运行时信息 —— 但这只是开发可移植软件的拼图之一。 为此目的， GNU开发了一套集成工具来完成Autoconf开始的工作： GNU构建系统， 其中最主要的组建是Autoconf、 Automake和Libtool。 在这一章， 我们将向你介绍这些工具，为你指出更多的信息来源， 并说服你使用整个GNU构建系统。</p>

<h3>2.1 Automake</h3>

<p>无所不在的make意味着makefile几乎就是发布自动构建规则的唯一可行方式， 但人们会 很快遇到它的很多限制。 它缺乏对自动依赖跟踪的支持， 不能在子目录中递归构建， 缺 乏稳定的时间戳（因为网络文件系统）等等。 这意味着开发者必须为每个项目重新发明轮 子， 而且经常容易出错。 由于不同系统上make的差异， 可移植性并非轻而易举。 在这之 上还要手工实现那些用户期待的标准目标（make install， make distclean， make unins tall， 等等）。 既然你要使用Autoconf， 你就必须在Makefile.in中插入重复的代码以识 别@CC@， @CFLAGS@以及其它由configure提供的替换。 Automake就是解决这些麻烦的。 Automake允许你在makefile.am中用一种比makefile更简单、更强大的语法说明你的构建需 求 ，然后生成一个可移植的makefile.in供Autoconf使用。例如，构建和安装一个 helloworld程序的Makefile.am看起来就像这样：
<pre>
	bin_PROGRAMS = hello
	hello_SOURCES = hello.c
</pre>
</p>

<p>k</p>

</body>
</html>
